パフォーマンスインサイトを利用してWordPressのDB負荷を分析してみた
はじめに
AWSチームのすずきです。
先日 Aurora(MySQL5.6)でも利用可能になったパフォーマンスインサイトを利用して、 WordPressで利用するデータベースの負荷分析を試みる機会がありましたので、紹介させていただきます。
設定
パフォーマンスインサイトの有効化/無効化はデータベースインスタンスの再起動を伴います。
メンテナンスウィンドウを利用した設定も可能ですが、今回、Webサイトへの影響を抑制しつつ即時反映を実現するため、パフォーマンスインサイトを有効化したリードレプリカを設置し、Auroraのフェイルオーバ機能を利用したインスタンスの交換を行いました。
パラメータグループ設定の追加
既存のデータベースはパフォーマンススキーマは利用しない設定であった為、新規パラメータグループを用意しました。
パラメータグループの設定値は既存を踏襲、パフォーマンススキーマ(performance_schema)の設定値のみ「0」→「1」と変更しました。
「T2」インスタンスを利用するAurora、リソース不足に陥る可能性があるため、パフォーマンススキーマを有効化した当パラメータグループの利用は避けてください。
パフォーマンススキーマの利用に伴う負荷上昇の目安はvCPU1コアあたり1%程度とされていますが、高い負荷が発生するデータベースでは、検証環境などを用いた事前確認をおすすめします。
リードレプリカ作成
- アベイアビリティゾーン、インスタンスクラスなどは既存のDBインスタンスの設定値を踏襲しました。
- パラメータグループは、先に用意したパフォーマンススキーマを有効にした設定を利用しました。
- 測定データの保持期間は7日、マスターキーはデフォルト、追加費用が発生しない設定としました。
リードレプリカ動作確認
- 起動したリードレプリカ、パフォーマンスインサイトダッシュボードに表示される事を確認しました。
フェイルオーバ
- リードレプリカがアプリケーションの動作するEC2からの利用に問題がない事を確認した後、手動フェイルオーバを実施しました。
- 切り戻し不要の判断がついた時点で、旧DBインスタンスは撤去しました。
パフォーマンスインサイト画面
RDSコンソールの「パフォーマンスインサイト」から、DBインスタンスを指定します。
初期状態では、指定したデータベースの直近1時間の「待機」の時系列グラフと、「SQL」の積算グラフが表示されています。
時系列グラフと、積算グラフは、「待機」「SQL」「ホスト」「ユーザー」をそれぞれ切り替えて表示する事が可能です。
待機
「待機」のグラフでは、データベースのCPU、IOに起因するボトルネックの発生が確認できます。
DBインスンタンスのvCPU数が基準線で示され、慢性的にセッション数が大きく超過している場合、DBインスタンスのスペック強化が望ましいことを示します。
SQL
「SQL」のグラフでは、指定期間中にデータベースを長く利用したSQLを確認可能です。
ドリルダウン操作を行う事で、実際に実行されたSQLを確認する事が可能です。
データベースに高い負荷をかけていたSQLを特定し、そのSQLや実行計画の改良、 場合によってはアーキテクチャを含めた見直しを図る事で、効果的な改善が期待できます。
ホスト
「ホスト」のグラフは、DB接続元のIPアドレスを確認する事が可能です。
高いデータベース負荷を発生させている環境の特定や、ログ回収の手がかりとなります。
ユーザー
「ユーザー」は、DB接続元ユーザ別の確認が可能です。
マルチテナントでデータベースを複数ユーザで利用されている場合や、BIツール用の接続ユーザが個人単位で払い出されている場合には有効です。
まとめ
Amazon RDS パフォーマンスインサイトを利用する事で、データベースのボトルネックや、 効果的な改善計画の策定に役立つ情報を簡単に得る事ができました。
パフォーマンスインサイトは、7日間のデータ保持期間、100万回のAPI実行までの利用であれば 追加費用なく利用できます。
Aurora(MySQL)ではパフォーマンススキーマの利用に伴う負荷は発生しますが、 その後の処理はAWS側で行われるため、性能影響などの副作用は少ない利用が期待できます。
Auroraデータベースの稼働状態を効率よく確認する手段の一つとして、パフォーマンスインサイトをご活用ください。
